Software applications, particularly commercially available software applications, are often quite complex, offering a variety of features and functions to the user. For example, various word processing, data management, accounting, illustration, animation, and development software applications have been available for a number of years. As computing power and resources have advanced, and as user's and their needs have become more advanced, such software applications have incorporated more features and functions and have generally become more robust and complicated.
Such advancements are continual, resulting in different versions of a particular software application being released over time. For example, as a fundamental change in a software application is developed, such as to accommodate a new operating system, a new file structure, a new processor, a fundamentally new or different feature, etc., the software application may be re-released as a new version (e.g., progressing from version 1.0 to version 2.0). Such version releases typically entail a substantial rewrite of the underlying binary code, or portions thereof, and may on occasion entail a complete rewrite of the underlying binary code. As can be appreciated, such version releases require substantial effort on the part of the developer to both create the software application binary code and to perform quality assurance in order to avoid releasing a non-functional or otherwise unsatisfactory version of the software. In particular, the entire software application typically must be re-tested, although only a small feature has been added, resulting in substantial time and effort being invested in the software application version update. It is not unusual for such efforts to cost a developer millions of dollars in order to release a new version of a software application. Accordingly, many software companies delay or forego completely the introduction of features which would otherwise enhance their software application.
Oftentimes it is desired to add a feature to, or modify a feature in, a software application which, although highly desirable, does not in itself warrant a version upgrade. Accordingly, although it is possible to introduce such a feature or change in a feature through the above described rewriting of the underlying binary code, such an undertaking is generally not practical for the introduction of an otherwise minor modification to the software application. Even where no fundamental changes to the software application are necessary to add a particular feature and only a relatively small amount of the software application binary code is affected by the revisions necessary to add the feature, and thus a “dot” release (e.g., progressing from version 1.0 to version 1.1) is possible rather than a full version release, substantial development and quality assurance efforts are typically implicated.
Accordingly, software developers have sometimes pre-coded protocols in software applications for interfacing the software application with later developed code in order to accommodate release of new features. For example, application programming interfaces (APIs) have been coded into releases of software applications in anticipation of the addition of later developed features. One or more feature may then be provided in a bit of code typically referred to as a “plug-in,” wherein the plug-in interfaces with the software application through the API to provide operation of the features. However, such APIs must be provided with all the appropriate protocols, software hooks, links, etc. in order to properly interact with the yet to be developed plug-in, and perform, the later developed features. Such a level of interfacing has generally been found to either require that the feature to be released in the future be substantially developed at the time the software application API is developed or that unusually accurate prophetic development of the API be done in order to provide desired and complete operation of the new feature with the software application.
Because of the relatively well defined and rigid interface provided by such APIs, even where the API has been properly configured to support a later developed feature through its associated plug-in, integration of the added feature has often been less than ideal. For example, interaction through such APIs has often provided a user experience in which it is clear that the added feature is not native to the software application. The user's interaction often requires steps or processes which are outside of, or otherwise different from, the steps or processes native to the software application. Moreover, the user interface presented by the plug-in through use of the API is often limited and/or does not result in a look and feel which is homogenous with that of the software application. Additionally, the number and types of functions that may be included in the user interface is limited by the API.
Another technique used by software developers for providing software applications with later developed features has been to provide predefined components within the software application. Such components include various software objects, such as software buttons, dialog boxes, etc., which may be accessed and used later to present a new feature. In essence, these components are predefined APIs and plug-ins which may be aggregated to provide a new feature. As with the APIs and plug-ins discussed above, the use of such components has been less than ideal. Because these components predefine the user interface components, the resulting user interface has been found to be draconian, lacking the ability to accommodate even minor variations. Accordingly, the result is a feature wherein it is clear that it is not native to the software application and a user interface which, in addition to being very limited, does not result in a look and feel which is homogenous with that of the software application. Additionally, the number and types of functions that may be included are limited to those predefined as components.